My macOS app reads the crashlog files directly and submits them to my server for analysis if the user allows it. Which means I get to see the original .ips files generated on Monterey. Now, these files appear to contain two JSON-formated records, the first detailing the app's properties. Here's a reformatted example of that as reported for my own app: { "app_name":"Find Any File", "timestamp":"2022-01-02 10:12:36.00 -0500", "app_version":"", "slice_uuid":"a15335de-4432-3b53-bcdf-381424a7a330", "build_version":"", "platform":1, "share_with_app_devs":0, "is_first_party":1, "bug_type":"309", "os_version":"macOS 12.1 (21C52)", "incident_id":"132818BA-3DBA-4B15-86CE-307BE961E7DC", "name":"Find Any File" } The problem for me here is that sometimes, like in this example, both the app_version and the build_version values are empty. That makes it difficult for me to figure out which version of my app caused the crash. I have 11 .ips crash reports, and when I compare the ones with valid version information against those missing them, the only consistency I find is that the value for is_first_party is 0 whenever I get valid versions, and 1 whenever I get empty values. Can anyone explain why this happens and how I can make this work in all cases? Note: One other developer (P.N.L.) has confirmed my findings, seeing empty versions as well, occosionally, and also directly related to the is_first_party value. (I've also asked this on SO,, but it's not a good fit there)

I keep getting a particular type of crash report for my macOS app (FAF) that I cannot figure out. Here's the top of the stack trace which all reports have in common: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib … objc_msgSend + 29 1 com.apple.AppKit … -[NSPathControl _performDragOfCell:fromMouseDown:] + 130 2 com.apple.AppKit … -[NSPathControl mouseDown:] + 300 3 com.apple.AppKit … -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4961 What I figured out so far: Is triggered by a click or double click on a segment of the NSPathControl. For some users it has been happening more than once, but not often enough for me to figure out what's behind it. I have not been able reproduce it even once. Leads to a "Segmentation fault: 11" Happens in macOS versions from at least 10.8 until the most current (11.4). In both Intel and ARM code. The call stack does not show any of my own code involved. The app's other threads are all idle. Some reports do not list any non-Apple extensions or dylibs as far as I can tell. When I googled "crash NSPathControl setHighlighted", I could only find a single other mention of it, but that crash even happened in Finder, on OSX 10.8.1. The person reporting it had quite a few other system extensions loaded but eventually figured out that it got fixed when he changed his Wacom tablet's behavior from not issuing a triple click any more. I tried to create triple clicks, along with combined drags, even using SteerMouse to have a triple click event generated by a separate mouse button, but to no avail. Has anyone else seen this type of crash? Any idea what may be behind this? I have two complete crash reports (with only some privacy related lines removed at the top) uploaded here: https://gist.github.com/tempelmann/5c519244ffc7a485afa66d546a9b9712 https://gist.github.com/tempelmann/315f8122b8079637cb5a9bf299ac380a

TL;DR I cannot install some Apple software because a certificate appears to have expired. How do I identify the culprit? I have been using Xcode 10.1 on 10.13.6 for a many years on my MacBook Pro, and suddenly it won't launch any more because it wants to install the "additional required components", but then fails at doing so with a weird "untrusted" error message. From the log file: Xcode[12324]: Package Authoring Error: PackageInfo bundle reference found without top-level bundle definition. Bundle will be skipped: <bundle id="*"></bundle> Xcode[12324]: Package: PKLeopardPackage <id=com.apple.pkg.MobileDeviceDevelopment, version=10.3.9000000000.1.1488876279, url=file:///Applications/Xcode10.1.app/Contents/Resources/Packages/MobileDeviceDevelopment.pkg> Failed to verify with error: Error Domain=PKInstallErrorDomain Code=102 "The package “MobileDeviceDevelopment.pkg” is untrusted." UserInfo={NSLocalizedDescription=The package “MobileDeviceDevelopment.pkg” is untrusted., NSURL=MobileDeviceDevelopment.pkg -- file:///Applications/Xcode10.1.app/Contents/Resources/Packages/, PKInstallPackageIdentifier=com.apple.pkg.MobileDeviceDevelopment, NSUnderlyingError=0x7f8240512710 {Error Domain=NSOSStatusErrorDomain Code=-2147409654 "CSSMERR_TP_CERT_EXPIRED" UserInfo={SecTrustResult=5, PKTrustLevel=PKTrustLevelExpiredCertificate, NSLocalizedFailureReason=CSSMERR_TP_CERT_EXPIRED}}} Everything else works fine on the system. All I changed recently, before this started happening, was to re-install 10.13.6 fresh, and then restore from a recent Time Machine backup, all in order to fix an iCloud issue that seemed to be related to SSL trust issues when contacting the iCloud sync server, but was fixed with this re-install. I've even re-downloaded the Xcode10.1.xip from Apple, but that makes no differences, it's not Xcode that's broken. The log suggests that a cert has expired, but which one would that be? I have looked at the Certificates in Keychain Access, but none of the ones that appear to be related to Apple are expired as far as I can tell. Maybe one is missing, but which? Any ideas how to analyse or fix this? (I need Xcode 10.1 because the macOS apps I make need to remain backward compatible with 10.11 and up, and I'm often debugging on High Sierra for that purpose. Besides, the same Xcode 10.1 works fine on two other Macs running 10.13.6.)

sample.ips.txt Xcode, MacSymbolicator and QuickLook all fail to consider the symbols from the lastExceptionBacktrace of a modern .ips crash report. I have attached a full report as an example (I had to change its extension to txt or I wouldn't be able to upload it - change it back to ips and then use Quicklook to see its contents, which will be missing the backtrace). Here's the excerpt that matters: "lastExceptionBacktrace": [ { "imageOffset": 992564, "symbol": "__exceptionPreprocess", "symbolLocation": 164, "imageIndex": 13 }, { "imageOffset": 106164, "symbol": "objc_exception_throw", "symbolLocation": 60, "imageIndex": 25 }, { "imageOffset": 274836, "symbol": "-[__NSDictionaryM setObject:forKeyedSubscript:]", "symbolLocation": 1176, "imageIndex": 13 }, This trace is missing from a symbolicated report - I only get to see the main threads. Here's the start of that report: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: Find Any File [2616] Path: /Applications/Find Any File.app/Contents/MacOS/Find Any File Identifier: org.tempel.findanyfile Version: 2.4.1 (355) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2024-01-09 11:31:33.8066 -0600 OS Version: macOS 14.3 (23D5043d) Report Version: 12 Anonymous UUID: E3DD5ECE-F28C-31BA-A2EA-DE39D4284163 Time Awake Since Boot: 990 seconds System Integrity Protection: enabled Crashed Thread: 11 Dispatch queue: Folder size calc (Macintosh HD) (QOS: UNSPECIFIED) Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Find Any File [2616] Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreAutoLayout 0x18cecbdd8 -[NSISEngine hasValue:forEngineVar:] + 284 1 AppKit 0x187f51894 NSViewActuallyUpdateFrameFromLayoutEngine + 128 2 AppKit 0x187f11790 -[NSView layout] + 636 Contrary to this, when I get a similar crash report from an older macOS version where it still uses the older .crash instead of .ips files, I get to see the backtrace and can symbolicate it as expected. This seems to be a major bug in the symbolicator for ips files, and it's been around for years. I'm surprised that this is still not taken care of. Am I the only one who's noticing this?

On macOS, if I mount two volumes whose name is the same, the second one gets renamed, by appending "-1" to its name. I need a method to determine the original volume name, i.e. without such a suffix. (Of course, I cannot blindly remove any "-" plus digits because the volume may actually be named like this.) I can find the original name when using the mount command in Terminal: //tt@192.168.61.121/NAS2 on /Volumes/NAS2 (smbfs, nodev, nosuid, mounted by tt) //tt@QNAS%28AFP%29._afpovertcp._tcp.local/NAS2 on /Volumes/NAS2-1 (afpfs, nodev, nosuid, mounted by tt) Here, I can tell that "/Volumes/NAS2-1" was originally named "NAS2" on the network. How do I determine the share's name without invoking such tools, but via CF or other macOS functions, with providing the path or URL of the mounted volume (such as "/Volumes/NAS2-1")?

When using the mount command on macOS, I can see mounted network servers like this: //tt@mynas.local/NAS on /Volumes/NAS (smbfs, nodev, nosuid, mounted by thomas) In this example "thomas" is my macOS user name, under which I mounted the "NAS" volume. But there's also the "tt" name before the "@" - and that's what I'm interested in getting - that's the user name known to the server, i.e. the name I logged in on the server when the connection prompt appeared. How do I get this name (tt) via macOS APIs? I can get it via "mount", but that requires parsing and is inefficient, and so I like to avoid that if possible. man mount mentions getfsent(), but in my testing it only lists internal volumes, not network volumes.

I have two apps that are exempt from the need to be sandboxed. One has been in the MAS since the first day in 2010, and the other was added only a bit later, when there still was no sandboxing in place. When Apple added requirements for sandboxing, they exempted existing apps like mine under certain conditions. For years, this was no problem, but lately, nearly every other time I submit an update or a TestFlight beta, I get the app rejected for not being sandboxed, even though I explain the situation in the app's Review Notes. It's always a tedious fight convincing the reviewer to let the app pass. And, of course, it delays my releases each time. It's frustrating and exhausting. Sadly, I cannot find any public documents that confirm my claim of this exemption. So, it's always possible that the reviewer may read my note but still not believe me. Are there others here who still have such non-sandboxed in the MAS? How do you deal with this? Or do you know of documents or websites that I can refer the reviewer to?

Update: Turns out it works for others, apparently, and I also found one of my Macs where it does work, too. So it must be something pertinent to my systems. Oddly, though, the same ones where it now fails used to work because I had TestFlight enabled there before. I have TestFlight set up on App Store Connect, and I have already about 50 testers subscribed. Today, I found that the Public Link does not work any more: Once TestFlight.app is installed, and one clicks the link to add my app to TestFlight, it always shows the error ""Unable to Open Link" in TestFlight.app: I've tried this on several Macs (Ventura and Sonoma), and with different Accounts, both where the app was already added or not. Is something generally broken, i.e. do others see the same issue with their TestFlight links, or is it just me? How do you suggest I get this resolved? Here's an example link I set up for this purpose - it only allows a handful of subscribers, so please do not actually subscribe but just see if you even get allowed to, or if you get the same error if you must try: https://testflight.apple.com/join/oV8NNojg And here's how it's set up:

Has anyone else seen this happen with their macOS apps in TestFlight? The situation: When I launch my app that's been downloading via TestFlight.app, it often comes up with its main window deactivated. Also, when I have open more than one window and close one, the other window doesn't come to front either. In either case, activating the app or clicking into a window will activate it properly. It feels as if there's another window that's not visible but somehow keeps getting activated. I have this happen on two Macs running both Sonoma and Monterey. Also, if I take the very same build that I had uploaded to TestFlight and run it directly, it works correctly. So I suspect that TestFlight somehow messes with my app's windows. If you want to test this yourself: Get the app thru this link: https://findanyfile.app/TestFlight/ Then launch it. Often, the Find window will already come up without being active. Activate it, then open the Preferences window by typing cmd-comma. Then close the Prefs window with cmd-W. This should re-activate the Find window but will instead leave it deactivated, and none of the menu shortcuts (such as cmd-comma, cmd-N or cmd-Q) work. That's the bug. I wonder how I can debug this to find a work-around for this odd behavior. E.g, I'd like to see if there is indeed a semi-hidden window causing this. How would I do this? I could probably make a new TestFlight build that queries the app's windows array and logs it. But are there other ways to query an app's windows? I tried AppleScript, but since my app isn't scriptable, I only get an error -1728 for tell app "Find Any File" to get windows.

I have an app in the App Store that doesn't need to be sandboxed (it's been in the MAS since 2010, before sandboxing became mandatory for new apps). I have run into an obscure bug that ONLY appears when the app was installed by TestFlight, but not when I run the same executable from before the upload (taken from the very same archive). I suspect it's a bug around the installed receipt or is codesign related, because that's the only things I am aware of that would be changed between my upload and the re-download via TestFlight. To debug this, I have built a small test project that I want to submit to DTS, demonstrating the bug in a clear and direct manner. But when I try to upload it, even for "internal testing" only, the upload gets rejected automatically because it's missing the App Sandbox entitlement. However, if I add the entitlement, then my app won't work, so I cannot enable it. Hence I need to get an exception from App Review so that they allow me test app being uploaded without the sandbox entitlement. I know that's possible because otherwise I'd not be able to upload my regular application, which I did just the other day. How do I get this resolved? Would a member of the App Store team please contact me? The Apple ID for the test project is: 410006334. Or, alternatively, you can also use the newer 6503298614 (I tried the other in hopes it would be allowed not to be sandboxed because I had created it long ago, but that didn't work out).

Imagine you accidentally made a build of your app with version 2 and uploaded that to App Store Connect for TestFlight even though you're still working on version 1.x and continue to do so with your public releases. Here's an example: The build 55 is the accidental 2.0 version, but the current releases are 209 and 210 with a lower string version. So, that one build of version 2 was a mistake. Sadly, you cannot remove it, even it has expired, even if it has never seen the outside of TestFlight. And it's a bit annoying too, because it stays up there at the top of your builds, and always presents the outdated version when you visit that page on App Store Connect. But worse is the fact that because of this, any version 1.x you release since then will not get you any crash reports or feedback that the user may have submitted to you. This is clearly a bug, and I was able to verify this just recently. I suspect this happens because Apple wants to avoid storing and forwarding reports for outdated versions, maybe to save space on their servers. That makes somewhat sense, though I've also had people finding crashes in older versions that were not fixed in the latest version, so I'd still like to get those reports from older versions. However, if Apple really only wants to keep crash reports and feedback msgs from the latest release, then Apple's mistake is that they use the unreliable string version to check which is the latest version instead of using the build number, which is ENFORCED by Apple to always be incrementing for each upload. If you are in the same boat, please comment so that we can make it clear to Apple that this is not an isolated issue.

I like to find a way to identify network volumes, and whether they're run by certain servers, e.g. specifically whether they're on a Synology NAS. Reason is that Synology, while apparently supporting the Spotlight-over-SMB API, comes with a lot of bugs, requiring me to work around them when searching on those volumes with the macOS Spotlight API. I could, of course, ask the user to "configure" each mounted volume in my software, but I'd rather do this automagically, if possible, as it's less prone to user mistakes. So, my question is: Is there a way to learn a bit more about the server of a mounted network volume? E.g., if I could learn its IP address, I could try to connect to it via http protocol and then maybe get a useful response that identifies it as being from Synology. Or, alternatively, can I tell which SMB volumes are served by a Mac, so that I can at least assume that those handle Spotlight calls correctly, while I assume anything else is buggy (so far, AFAIK, Synology is the only other SMB server that supports Spotlight search). I've tried to find some data in the IORegistry, but that doesn't seem to store anything about network vols. The statfs function doesn't seem to give me anything for that either, nor do the various fcntl calls as far as I could tell. I also checked with the DA apis, e.g.: DASessionRef daSession = DASessionCreate (NULL); CFURLRef furl = CFURLCreateWithFileSystemPath(NULL, CFSTR("/Volumes/TheNAS"), kCFURLPOSIXPathStyle, true); DADiskRef daDisk = DADiskCreateFromVolumePath (NULL, daSession, furl); if (daDisk) { CFDictionaryRef daInfo = DADiskCopyDescription (daDisk); NSLog(@"%@", daInfo); } However, this only prints basic information: DAVolumeKind = smbfs; DAVolumeMountable = 1; DAVolumeName = TheNAS; DAVolumeNetwork = 1; DAVolumePath = "file:///Volumes/TheNAS/"; Where, then, does Finder's "Get Info" get the smb path from, for example?

My app (Find Any File) behaves strangely on Sequoia: When the code calls the window's makeFirstResponder on the NSSearchField item in the window's toolbar, and if the toolbar is currently showing the small loupe icon, it should: Switch to showing an NSTextView in place of the loupe icon Make the text view the first responder so that the user can type in it. This used to work reliably before macOS 15, but in 15.0.1 and also the current 15.1 beta it often misses step 1 or or step 2. When it misses step 1, then the window's first responder reports back to it's set to the text field, but its frame is very narrow (width is 4 isntead of 192). And when it misses step 2, then the textview is visible but hasn't gained focus - instead, the main window is the first responder. This happening is quite random. I find no pattern. Even worse, after calling makeFirstResponder, if I check the window's first responder, it's always the expected NSTextView, even if I delay the check with dispatch_async(dispatch_get_main_queue(), ^{ …. So I cannot even reliably detect when this goes wrong in order to act on it. Has anyone else noticed this to happen in their apps?

macOS 15 has added a new "Local Network" permission under Security & Privacy. I had a bug in my app that led to a crash when the user denied this permission. Now I've fixed it and would like to verify that it all works fine. The problem is: I need to remove my app from the settings so that macOS will show the prompt again (e.g. to verify that my custom message appears correctly). Usually, sudo tccutil reset All would do the trick. But not for this permission! The apps do not get cleared with this command. So, there's two issues: tccutil should remove it but doesn't. How can I remove this settings? Update I had a look at the "TCC.db" (see https://www.rainforestqa.com/blog/macos-tcc-db-deep-dive), and it seems to me that the Local Network permission isn't even managed by the TCC system, as it doesn't appear in it. This is odd.

I have several ObjC based apps in the App Store and used to validate the receipt file inside the app in my code, and then reject it with exit(173) if it's invalid, which did trigger macOS to update the receipt if possible. This isn't working any more in recent macOS versions, where the user is instead just told that the app is damaged, and they need to re-install it manually. Which sucks. So I wanted to update my code. I read about SKReceiptRefreshRequest, which is supposed to re-download and install the receipt file, if I understand it correctly. I implemented the code but now have trouble verifying that it works as intended, and does this in a user friendly way. I found in my tests that macOS now caches the receipt in ~/Library/Caches/com.apple.appstoreagent/fsCachedData and then hardlinks the file into the app. BTW: Sadly, this also requires that the app is located on the startup volume or the system will refuse to install the receipt, which wasn't a requirement in past times. Now, if the receipt is already present in the cache folder, then my code works - the receipt gets re-linked. But what if the cached receipt isn't there, yet? Such as that the user had copied the app from another Mac over to a freshly installed Mac? In the past, when the user then launched the app on the new Mac, he'd be prompted to login to the MAS and if that worked, the receipt would get installed and the app launched. Basically, the question is: What if the receipt validation fails in my app and I request a new receipt, but the user has not yet logged into MAS (e.g. new computer)? To simulate this, I logging out of the MAS and TestFlight, deleting all copies of the app and then run the app that I had copied from another Mac where it was authorized with a valid receipt for that device. If I do this with the old version that uses exit(173), I get these two messages in macOS 15.2: The second one is especially terrible because it shows the translocated path, which the average user surely get quite confused, and then maybe even search in vain for the app in there and get frustrated. But that's out of my hands. Sigh. Now, that was proving that the old method with exit(173) isn't working any more and needs to be changed in my apps. Since I'm still developing (testing) this new behavior, the app is therefore not in the MAS yet - the only way for me to test this is to use TestFlight. However, running a Testflight app copied from another Mac leads to this error: That is not helpful in simulating what would happen if this app was released in the MAS. This won't let me find out what happens if my app is run on a Mac where the receipt fails and I ask it to load it via SKReceiptRefreshRequest and if the user is NOT yet logged into the MAS account for this purchased app of his/hers. That leaves only one option: Release the app with untested code and hope for the best. Contrary to this new behavior, the old method did let me test this easily because I would just use the special App Store tester account with the MAS app, i.e. the built MAS app would, when I launched it locally, request for a login and I'd provide my tester's account. But this isn't available any more, apparently. What a mess.